Codecov Report

Merging #216 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #216   +/-   ##
=======================================
  Coverage   95.64%   95.64%           
=======================================
  Files          34       34           
  Lines         942      942           
=======================================
  Hits          901      901           
  Misses         41       41           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b8fc1ee...4fddcbe. Read the comment docs.

I very much prefer format (like fastapi) instead of reformat which feels redundant.

I'm not sure about adding pre-commit Lee. It will be an entry barrier, and it's not adding much. It will be a pain-point during the sprints.

From my perspective:

• Our CI catches lint and test errors just fine.
• We don't make mistakes often when creating PRs to justify pre-commit.
• We can squash commits from contributors if they don't match conventional commits.

What do you think about it?

I very much prefer format (like fastapi) instead of reformat which feels redundant.

I totally agree with it 😄

I'm not sure about adding pre-commit Lee. It will be an entry barrier, and it's not adding much. It will be a pain-point during the sprints.

From my perspective:

* Our CI catches lint and test errors just fine.

* We don't make mistakes often when creating PRs to justify pre-commit.

* We can squash commits from contributors if they don't match conventional commits.

What do you think about it?

I agree with your points of view but also like pre-commit 😆. I don't have a strong option on whether to use pre-commit after reading your comments. Here's my thought on why using pre-commit might be good and might not be a huge entry barrier. 🙂

1. pre-commit is optional. We're not able to force contributors to install it when they're to contribute. It's a kinda helper for them to meet our requirements. But even if they don't, we could still handle it as you said.
2. As a contributor, I like to learn best practices from contributing to open source projects, especially in a sprint. (I actually learn a lot from this project) Even if the contributors run into a problem, I don't think it will take to much of our time to instruct them during the sprint.
3. As a maintainer, it can save some of our time to do those trivial kinds of stuff.

You are right, but everything we add adds more maintenance, plus what's the point of the extra noise if not used?
I remember my first contributions/projects and there were things there were super confussing and I was lost in a sea of questions haha (specially with tox).
But okay, If you think it will really add value to us, I'm in for it, we can try it (worst case if we feel like it's not adding value, we can remove it as it's not part of the src code).

Yes, I think it will add value to us. 🙂 But I also understand your concern. We can test it in euro python 2020 sprint and pycon tw 2020 sprint (I will host one in Taiwan 🇹🇼) to see whether we will encounter the problem you mention. I'll merge it for now.